Access control is paramount to computer security. To protect the integrity of computer systems and the confidentiality of important data, various access control schemes have been implemented to prevent unauthorized users and malicious attackers from gaining access to computer resources.
To ensure the comprehensiveness of computer security, access control is often implemented on various levels. For instance, on the level of one computer, a user is typically required to go through a logon procedure in which the computer determines whether the user is authorized to use the computer. In addition, on the level of a computer network, a user is commonly required to go through a user-authentication process for purposes of controlling the user's access to various network services. Even after a network access control server has authenticated the user, the user may still have to request a permit for a specific server in order to access that service. Various schemes based on different protocols, such as the Kerberos 5 protocol, have been proposed and implemented for controlling network access control by means of user authentication.
Generally, the user logon for a computer and the user authentication for network access control are two separate procedures. Nevertheless, to minimize the burden on a user in dealing with the different access control schemes, the user logon and the user authentication for network access are sometimes performed together. For example, in the case where the user authentication is implemented under the Kerberos protocol, when the user logs on the computer, the computer may also initiate a Kerberos authentication process. In the Kerberos authentication process, the computer contacts a Kerberos Key Distribution Center (KDC) to first obtain a ticket-granting ticket (TGT) for the user. The computer can then use the TGT to obtain, from the KDC, a session ticket for itself. As networks have evolved, there has been a trend to have multiple tiers of server/service computers arranged to handle client computer requests. A simple example is a client computer making a request to a World Wide Web website via the Internet. Here, there may be a front-end web server that handles the formatting and associated business rules of the request, and a back-end server that manages a database for the website. For additional security, the web site may be configured such that an authentication protocol forwards (or delegates) credentials, such as, e.g., the user's TGT, and/or possibly other information from the front-end server to a back-end server. This practice is becoming increasingly common in many websites, and/or other multiple-tiered networks.
Delegation and other like techniques are useful when all of the servers/services and the client agree to use the same authentication process. There is not, however, just one authentication process in use today. Co-pending U.S. patent application Ser. No. 09/886,146 presents improvements for controlling the delegation.
If the user is authenticated for a network/system, then there is usually one or more additional authorization access control checks to prevent the user from accessing resources that he/she is not authorized to access. Once a user has been authenticated and passed the applicable access control checks, the user is said to be “authorized”. In certain systems, for example, access control is based on having access control lists (ACLs) for the various services and resources (i.e., objects). An ACL usually includes access control entries (ACEs), in which zero or more security identifiers (SIDs) may be included. SIDs may be associated with one user or groups of users allowed to access the object. If there are no SIDs in the ACL, then no user will have access to the object. If there are SIDs in the ACL, then users that can produce at least one matching SID will be allowed to access the object.
Thus, when an authenticated user logs on, an authentication context is created for the user, for example, by generating a token (e.g., an access token) that is associated with the user. The token typically includes SIDs that are associated with the user. For example, the user's token may include a unique SID assigned to the user plus a group SID assigned to the user's business department. When the user attempts to access an object the object's ACL is compared to the user's token. If the user's token includes at least one SID that matches a SID within the object's ACL, then the authenticated user is authorized to access the object in some manner. For example, the user may have read and write permissions for a file generated by other members of his/her business department (i.e., another group member).
Such authorization schemes tend to work very well for systems that are carefully controlled and managed. For example, an enterprise level computer network within a corporation usually provides a cohesive environment wherein the users and ACLs can be carefully controlled by a centralized and/or distributed authentication and access control system. On the other hand, for very large networks, e.g., the Internet, and/or otherwise significantly non-cohesive networks, authentication and access control can be much more difficult, especially when there is a desire to serve as many of the users as possible, including users that do not have local access control accounts. As software programs and resources migrate towards network-based services, the need to be able to authorize user activity associated with such network services will further increase.
Consequently, there is a need for improved authorization methods and systems. Preferably the methods and systems will allow users that are authenticated by a trusted external resource to gain some controlled level of access to certain objects without requiring the user to also have a unique user account associated with the object. Moreover, the methods and systems should not significantly degrade the scalability of arrangements that are capable of providing access to objects for very large numbers of users.